This doesn't fully solve the problem because you pass exponent which may mean this is only the part of the exponent but the function will treat it as full. So this computation may give incorrect results.

We can take inspiration from the EELS implementation, which resolve this problem in an elegant way.

According to eip-7883, the iteration count is derived from the exponent. However, in practice we only need at most 32 bytes of the exponent.

def calculate_iteration_count(exponent_length, exponent):
    iteration_count = 0
    if exponent_length <= 32 and exponent == 0:
        iteration_count = 0
    elif exponent_length <= 32:
        iteration_count = exponent.bit_length() - 1
    elif exponent_length > 32:
        iteration_count = (16 * (exponent_length - 32)) + ((exponent & (2**256 - 1)).bit_length() - 1)
    return max(iteration_count, 1)

• When exponent_length <= 32, we can compute the bit length of the full exponent directly.
• When exponent_length > 32, we mask the exponent to its 32 bytes and calculate the bit length of that portion: (exponent & (2**256 - 1)).bit_length() - 1

As a result, we only need to fetch the first 32-byte word of the exponent input (exponent_head) to perform this calculation, instead of processing the entire exponent.

This feels a bit too much for me. I generally struggle with some data types in EEST which have a lot of interconnected options and flags.

This could be a normal constructor. And you can fix the properties directly in the constructor like:

length_base = declared_base_length if  declared_base_length not None else len(base)

I do not notice this before, it seems like we already have the same functionality in calculate_iteration_count, should avoid duplicate here

Thanks! Nice catch - updated in latest commit.